In an automation environment such as a factory, a processing plant, a material handling facility, or any other suitable venue at which automation is present, a wide array of equipment is utilized. This wide array of equipment can include, for example, various manufacturing machines such as batch processing machines, material handling machines, fabrication machines, welding machines, packaging machines, finishing machines, transportation machines, and the like. The equipment in an automation environment can be monitored and controlled via a plurality of controllers coupled to a plurality of sensors, I/O modules, drives, etc.
Also, associated with the industrial machines and/or controllers are human-machine interface (HMI) devices. HMI devices can include physical-type interfaces including a plurality of physical buttons, switches, knobs displays, indicators, and so on. Increasingly, however, conventional HMIs are being replaced with graphical user interfaces (GUIs) displayed, for example, on display screens. In some cases, the displays screens can be touch screens which can handle user input while displaying output. For instance, machines can include terminals (e.g., touch screens) embedded therein that can execute applications configured to generate the HMI GUI, receive user input, process user input, etc. In another example, terminals can be standalone devices, e.g., general purpose computing devices such as a personal computer, located remote or separate from the machines. However, such standalone machines can execute similar applications and/or provide similar control of machine functions as the embedded counterparts. Further, terminals can be of a portable nature such as a mobile operator interface device, e.g., a tablet computer, which can be carried to, and connected with, a plurality machines as desired. It is to be appreciated that while the term terminal is utilized hereafter, the term terminal encompasses all instances of devices and configurations as described, and accordingly includes personal computing device, HMI, machine located terminal, machine located HMI, test system, stand alone terminal, stand alone HMI, and the like.
To provide rich HMI applications, the terminals can communicate with controllers managing machines associated with the applications. Via communications with the controllers, HMI applications can retrieve controller variables (e.g., machine conditions, machine inputs, machine outputs, etc.) for display on the GUI and can forward commands received via the GUI to the controllers. The commands can operate to change controller variables, execute processes, make changes to running processes, override automated actions with operator-supplied actions, etc.
To enable such communications, the application, at design time, can be configured with connection information, which is utilized to locate and connect with controllers once the application is deployed on a terminal. The configuration information (e.g., such as the connection information but can also include security information) is typically fixedly associated with the application and, in particular, an application project employed to build and deploy the application to a terminal. Due to this tight coupling, an HMI application, when created, becomes coupled to a particular machine.
For instance, a machine builder (e.g., an original equipment manufacturer (OEM)) can create an HMI application with one configuration and deliver the machine (with application) to a customer where the configured is modified in accordance with the customer's systems. Several iterations of this procedure can occur when, for example, a problem occurs and the machine or application needs servicing or updating. The application, when returned to the manufacturer, is reconfigured to original settings for continued development and testing. When an updated application is returned to the customer, the application is yet again reconfigured. Such frequent reconfigurations can lead to errors or mistakes.
In another example, an identical application can be deployed to similar machines placed with a factory (e.g., redundant process lines). Conventionally, the application is duplicated and respective duplicates are configured for a particular machine. Handling multiple project duplicates and configurations can lead to mishandling and other configuration errors. Similarly, users who desire to maintain test systems, pilot production systems and/or primary production systems also maintain duplicate application projects and configurations. Such deployment can be by a variety of means. In one aspect an application can be downloaded directly to any one of a machine, HMI, controller, etc. In another aspect an electronic file can be created which contains the configuration application and configuration settings for target equipment (e.g., a plurality of machines) with a user moving from one machine, HMI, controller, etc., to another and downloading/installing the application individually by such means as a FTP file transfer or via a removable memory card such as a USB memory stick, SD memory card, and the like.
Typically, mechanisms to manage multiple configurations for HMI application, controller applications, and/or other software applications within an industrial automation environment involve manual processes to create multiple copies, and to change settings for the copy when the application deployed according to a different configuration. Another approach is to employ an automated tool which enables a configuration to be exported, altered, and re-imported. In yet another conventional approach, an application program interface (API) can be leveraged to change configurations back and forth. In the aforementioned techniques, however, end user customers are burdened with a time consuming and error prone task for managing an application project.
Further, in another approach, a designer may require a first version of an application is loaded onto a test/pilot system while a second version of an application is loaded onto one or more machines comprising a production system which is being modeled/mimicked by the test/pilot system.
In a further approach, a manufacturer/supplier (e.g., OEM) of a machine may supply the same machine version to a plurality of end users/manufacturers. The OEM may desire to maintain a single project comprising configuration settings for each of their customers. Hence, a requirement can evolve where a plurality of applications have to be developed and managed in accord with their individual customers requirements. Accordingly, a single application may have a plurality of revision levels such as customer A receives revision 1 of a GUI visualization, while customer B receives revision 2 of the GUI visualization. Hence, each time an application is deployed appropriate content, e.g., specific to a particular customer, is deployed.
The above-described deficiencies of conventional HMI application settings management solutions are merely intended to provide an overview of some of the problems of conventional systems and techniques, and are not intended to be exhaustive. Other problems with conventional systems and techniques, and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.